Fundamentally, a database is a computerized record-keeping system in which large amounts of information may be stored in a structured manner for ease of subsequent retrieval and processing. Large databases are generally managed through data base management systems (DBMS's). A DBMS provides an operational environment through which a user may retrieve or update previously stored information. In one type of DBMS, referred to as a relational database system, information is stored in tables, with each table having one or more columns and one or more rows. One well-known example of a relational database system is the DB2® database environment. (DB2 is a registered trademark of International Business Machines Corporation of Armonk, N.Y.). Within a DB2 environment, database tables are created within a tablespace, which can be simple, segmented, or partitioned.
Databases may be characterized as comprising two types of “objects”—data objects and index objects. Both data and index objects are typically embodied as files stored on one or more direct access storage devices (DASDs). Index objects are typically stored in an index. The index is used to search information in tables because scanning an index can be more efficient than scanning an entire table for information. As is known, an index includes a set of pointers that are logically ordered by the values of a key. An index key is the set of columns in a table used to determine the order of index entries. Thus, each entry of an index typically has an index key or search-key value and a pointer to the row of the table containing that value.
In a database environment, there are a number of reasons why a user may wish to create or rebuild an index. In one reason, temporary indexes may be created to support specific processing needs, such as batch processing. Currently, the user may enforce read only access to the source data while the temporary indexes are being built. Alternatively, the user may never drop indexes so that an overhead of updates must be maintained in the database environment.
In another reason, existing indexes may be deleted to provide faster loading of data with a LOAD utility. This is more common with a LOAD RESUME operation. Consequently, indexes must be rebuilt after the load. Currently, the user may enforce read only access to the source data while new indexes are being built. Alternatively, the user may use an operation to do partial rebuilds. One example of such an operation for partial rebuilds is the LOAD RESUME SHRLEVEL CHANGE operation available in the LOADPLUS utility from BMC Software, Inc.
Large databases can have hundreds of gigabytes to tens of terabytes of information so that the time required to build an index can be significant. Therefore, enforcing read only access to source data can be particularly undesirable due to the amount of time required to build an index. Thus, it would be beneficial to provide a technique to build an index for a database that is more time efficient than current techniques. The subject matter of the present disclosure is directed to overcoming, or at least reducing the effects of, one or more of the problems set forth above.